-
-
Notifications
You must be signed in to change notification settings - Fork 89
aarch64 build fixes for 2.19.1 (WIP) #465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( I do have some suggestions for making it better though... For recipe/meta.yaml:
This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/21003886856. Examine the logs at this URL for more detail. |
|
also need to check this line from the build output:
|
This is fine. We always use the newest C++ standard library implementation, even if you compile with older compiler versions. That works because the standard libraries (libcxx and libstdcxx) are highly backwards compatible |
d60afae to
d2a2a5f
Compare
- remove previous python package id limits - fix build issue in xla Co-Authored-By: H. Vetinari <[email protected]>
d2a2a5f to
dd5aec0
Compare
|
Same error as you noted in the OP already This will probably require patching the bazel files |
…er than the build host which is passed in.
|
Spent some time trying to get to bottom of bazel system and interaction with building the wheels. I could not see how the platforms// etc gets populated or an equivalent 'target' platform - but a simple (dirty) change of telling the python script that the target is arm64 resolved it. Do any of the maintainers here know a better attribute/variable that would be the actual build target - my patch is simple but the build now completes successfully: (obviously this patch is conditional on being a linux-aarch64 build..) |
The docs suggest that '@platforms//cpu' is supposed to be the result of bazel --cpu .. - in our case, the target cpu (aarch64), so why that's not the case in practice, I don't know. |
|
@conda-forge-admin, please rerender |
|
@conda-forge-admin, please rerender |
This PR will get us going again on linux-aarch64
Work in progress:
Locally this reaches the end of the compilation phase (no C++ compile errors :0), but there's a wheels problem:
a) it looks to me like it's trying to make x86_64 ones when doing aarch64 - although that does not error (surely it should.) - smells like it's from the bazel part of the build:
and
Checklist
0(if the version changed)conda-smithy(Use the phrase@conda-forge-admin, please rerenderin a comment in this PR for automated rerendering)